Charging in ims networks for sessions that are transferred between access networks

ABSTRACT

IMS networks and methods are disclosed for charging for a session of a dual mode device that is transferred (seamless handover) from a first access network to a second access network. When a session is transferred between access networks, multiple charging identifiers (e.g., ICID) are assigned to the session. One or more network elements in the IMS network identify both an original ICID and a handover ICID for the session, and insert the original and handover ICID in a charging message that is transmitted to a charging system. The charging system then inserts the original ICID and the handover ICID in a CDR for the session. When the session ends, the charging system may use the original ICID and the handover ICID to correlate multiple CDRs for the session. Thus, even if CDRs for the same session have different ICIDs, the charging system is able to correlate the CDRs.

RELATED APPLICATIONS

This application is the National Stage under 35 U.S.C. 371 ofInternational Application No. PCT/US07/87985, filed Dec. 18, 2010, whichis incorporated by reference herein.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention is related to the field of communication networks and, inparticular, to providing for offline charging in IMS networks forsessions of dual mode devices that are transferred between accessnetworks (e.g., a session transferred (seamlessly handed over) from aGSM network to a WiFi network).

2. Statement of the Problem

One type of communication network gaining popularity is an IP MultimediaSubsystem (IMS) network. As set forth in the 3^(rd) GenerationPartnership Project (3GPP), IMS provides a common core network having anetwork architecture that allows for various types of access networks.The access network between a communication device and the IMS networkmay be a cellular network (e.g., CDMA or GSM), a WLAN (e.g., WiFi orWiMAX), an Ethernet network, or another type of wireless or wirelineaccess network. The IMS architecture is initially defined by the 3GPP toprovide multimedia services to communication devices over an InternetProtocol (IP) network, as IP networks have become the most cost savingsbearer network to transmit video, voice, and data. Service providers areaccepting this architecture in next generation network evolution.

For a typical session (or call) within an IMS network, user equipment ofan IMS subscriber initiates the session through an access network, suchas a CDMA network, a GSM network, an IP network, a WiFi network, a WiMAXnetwork, etc, by transmitting the appropriate signaling messages (i.e.,SIP messages). The access network then routes the signaling messages tothe IMS network. If the access network does not use the same signalingprotocols as the IMS network (e.g., SIP), then the access network mayroute the signaling messages to the IMS network through an appropriategateway. A serving-call session control function (S-CSCF) in the IMSnetwork receives the signaling messages and attempts to establish thesession in the appropriate manner. When the session is established, theS-CSCF may also contact one or more application servers (AS) in the IMSnetwork to provide services for the session, such as voicemail, callforwarding, etc.

To provide offline charging for the session, each of the IMS networkelements (e.g., S-CSCF and AS) handling the session generates chargingmessages typically in Diameter Rf protocol. For instance, a networkelement transmits a start charging message, such as a DiameterAccounting Request (ACR[start]) message, to a Charging Data Function(CDF) in the IMS network at an initial triggering event. Periodicallyduring the session, the network element transmits interim chargingmessages, such as a Diameter ACR[interim] messages, to the CDF. Atending triggering event, the network element transmits a stop chargingmessage, such as a Diameter ACR[stop] message, to the CDF. Each of thecharging messages includes an IMS Charging Identifier (ICID) that isassigned to the session so that the charging messages may be correlatedin the CDF.

The CDF then processes the charging messages received from the networkelements that are serving the session to generate Charging Data Records(CDR) for the session. The CDF then transmits the CDRs to a ChargingGateway Function (CGF) that correlates the CDRs that have been generatedfor the session based on the ICID. The CGF then transmits the correlatedCDRs to a billing system. The billing system may then resolve anycharging for the session based on the correlated CDRs.

Some service providers allow for dual mode service. Dual mode serviceallows an IMS device to communicate with different types of accessnetworks that utilize different protocols. As an example, dual modeservice may allow an IMS device to communicate with a cellular network,such as a CDMA network or a GSM network, and also communicate with awireless LAN, such as a WiFi network or WiMAX network. IMS devices thatare able to receive a dual mode service are referred to as dual modedevices or dual mode handsets.

When a dual mode device initiates or accepts a session over a firstaccess network (for example a non-IMS network, such as a GSM network),the mobile management application and network domain selection functionwhich may reside in a dual mode handover application server or anindependent server will communicate with an S-CSCF, and change therequest-URI. The S-CSCF in the IMS network receives the sessioninitiation message and establishes the session with a destination. Afirst session leg is then established between the dual mode device andthe destination with the first access network acting as the accessnetwork for the IMS network. In response to the first session leg beingestablished, an ICID is assigned to the session, which is referred toherein as an original ICID. The S-CSCF and other network elementsserving the session generate charging messages as described above thatinclude the original ICID.

If the dual mode device transfers to a second access network, such as aWiFi network, then the dual mode device transmits another sessioninitiation message (e.g., another SIP INVITE message) to the IMS networkthrough the second access network. When a dual mode device transfersfrom one access network to another access network, this is oftenreferred to as a “handover”. The S-CSCF in the IMS network receives thenew session initiation message, and forwards the message to a handoverapplication server. The handover application server operates toestablish a second session leg between the dual mode device and thedestination with the second access network acting as the access networkfor the IMS network. The handover application server establishes thesecond session leg so that the session is not interrupted in thehandover to the second access network. The end user keeps the sessionwhen actually the session is seamlessly handed over from the firstaccess network to the second access network. The end user may not noticethe handover during the session. The first session leg is also torndown.

In response to the second session leg being established, another ICID isassigned to the session, which is referred to herein to as a handoverICID. The S-CSCF and other network elements serving the session generateadditional charging messages as described above that include either thehandover ICID or the original ICID depending on the dialog that triggersthe charging message. Thus, the CDF receiving the charging messages forthe session will generate CDRs with the original ICID and will alsogenerate CDRs with the handover ICID.

One problem in present IMS networks is that there is no effective way tocorrelate CDRs for a session when there was a handover from one accessnetwork to another access network. When there are multiple handoversduring one session or call, many different ICIDs are generated. The CDRsfor the same session will have different ICIDs when it is handed overfrom one access network to another. Thus, the CGF is not able tocorrelate the CDR for the session. As a result, the end user may beunder-billed or over-billed for the session.

SUMMARY OF THE SOLUTION

Embodiments of the invention solve the above and other related problemsby having a network element in the IMS network, such as a handoverapplication server, identify not only the original ICID but also thehandover ICID for a session that has been handed off from one accessnetwork to another. When charging is triggered in the network element,the network element inserts the handover ICID and possibly otherhandover information in the charging messages along with the originalICID. The charging system (e.g., CDF/CGF) that receives the chargingmessages may then generate a CDR for the session that includes theoriginal ICID and the handover ICID. If multiple CDRs are generated forthe session, then the charging system is able to correlate the CDRsbased on the original ICID and the handover ICID. As a result, the enduser is advantageously billed the correct amount because the CDRs forthe session are accurately correlated.

One embodiment comprises an IMS network adapted to provide charging fora session of a dual mode device that is transferred from a first accessnetwork to a second access network. The IMS network includes a networkelement, such as an S-CSCF or a handover application server, and acharging system. The network element identifies a triggering event forcharging during the session, and identifies a transfer of the sessionfrom the first access network to the second access network. With thesession being transferred from the first access network to the secondaccess network, the network element identifies a handover chargingidentifier (e.g., handover ICID) assigned to the session over the secondaccess network in addition to an original charging identifier assignedto the session over the first access network. The network element thengenerates a charging message (e.g., a Diameter ACR message) for thesession and inserts the handover charging identifier and the originalcharging identifier in the charging message. The network element thentransmits the charging message to the charging system.

The charging system receives the charging message from the networkelement, and processes the charging message to identify the originalcharging identifier and the handover charging identifier. The chargingsystem then inserts the original charging identifier and the handovercharging identifier in a Charging Data Record (CDR) for the session. Atthe end of the session, the charging system processes the originalcharging identifier and the handover charging identifier in the CDR toidentify other CDRs for the session having at least one of the originalcharging identifier and the handover charging identifier. The chargingsystem then correlates the CDRs for the session based on the originalcharging identifier and the handover charging identifier, and transmitsthe correlated CDRs to a billing system.

Because both the original charging identifier and the handover chargingidentifier are reported to the charging system and inserted in one ormore CDRs, the charging system is able to identify CDRs for the samesession even though the CDRs may have different charging identifiers. Asa result, more accurate charging may be realized for the session.

The invention may include other exemplary embodiments described below.

DESCRIPTION OF THE DRAWINGS

The same reference number represents the same element or same type ofelement on all drawings.

FIG. 1 illustrates a communication network in an exemplary embodiment ofthe invention.

FIG. 2 is a flow chart illustrating a method of generating chargingmessages in network elements in an IMS network in an exemplaryembodiment of the invention.

FIG. 3 is a flow chart illustrating a method of processing chargingmessages in a charging system to generate CDRs in an exemplaryembodiment of the invention.

FIG. 4 is a flow chart illustrating a method of correlating CDRs in acharging system in an exemplary embodiment of the invention.

FIG. 5 illustrates another communication network in an exemplaryembodiment of the invention.

FIGS. 6-8 are message diagrams illustrating messaging used in a sessionover the communication network of FIG. 5 in an exemplary embodiment ofthe invention.

DETAILED DESCRIPTION OF THE INVENTION

FIGS. 1-8 and the following description depict specific exemplaryembodiments of the invention to teach those skilled in the art how tomake and use the invention. For the purpose of teaching inventiveprinciples, some conventional aspects of the invention have beensimplified or omitted. Those skilled in the art will appreciatevariations from these embodiments that fall within the scope of theinvention. Those skilled in the art will appreciate that the featuresdescribed below can be combined in various ways to form multiplevariations of the invention. As a result, the invention is not limitedto the specific embodiments described below, but only by the claims andtheir equivalents.

FIG. 1 illustrates a communication network 100 in an exemplaryembodiment of the invention. Communication network 100 includes a firstaccess network 102, a second access network 103, and an IMS network 110.IMS network 110 includes a serving-call session control function(S-CSCF) 112, a handover application server 114, and a charging system116. Communication network 100 further includes a billing system 120(which may actually be part of IMS network 110). IMS network 110 mayinclude other network elements that are not shown for the sake ofbrevity, such as one or more proxy-call session control functions(P-CSCF), a BGCF (for a voice call to GSM and CDMA, the S-CSCF willroute the call to BGCF first then BGCF routes to an MGCF), one or moremedia gateways, etc.

Access networks 102-103 comprises any networks that provide access toIMS network 110 using different protocols. For instance, access network102 may comprise a cellular network, such as a CDMA network or a GSMnetwork, while access network 103 comprises a wireless LAN, such as aWiFi network or WiMAX network. Each of access networks 102-103 may bewireline networks or wireless networks.

Access networks 102-103 are illustrated as providing service to a dualmode device 106. A dual mode device comprises any wireless and/orwireline device adapted to communicate with different types of accessnetworks that utilize different protocols. Dual mode device 106 has thecapability of communicating with either of access networks 102-103 inorder to access IMS network 110 and its associated services, along withother access networks not shown in FIG. 1. Dual mode device 106 also hasthe capability of switching between access networks 102-103 during anestablished session.

Within IMS network 110, S-CSCF 112 comprises any system, server, orfunction adapted to establish, maintain, or tear down a session in IMSnetwork 110. Handover application server (AS) 114 comprises any system,server, or function adapted to provide a handover service for a sessionof dual mode device 106. Typically, the handover application server 114may be a Voice Call Continuity (VCC) application server adapted toprovide voice call continuity when the user is moving between a CircuitSwitched (CS) domain and an IMS domain. The handover application serveror VCC application server may include a mobile management AS option (notshown) and a network domain selection function (not shown) to performhandover between different wireless domains. The mobile management AS iswhere the IMS core network emulates an MSC to a circuit-switched networkfor subscriber access on IMS network. The network domain selectionfunction determines call delivery routing. The service logic of thenetwork domain selection function routes the session to the appropriatedomain (IMS or circuit-switched) based on the current state ofregistration within the domains and operator and subscriber preferences.Handover application server 114 processes signaling messages for thesession to provide a handover from access network 102 to access network103 (or vice-versa) without interruption of the session. Charging system116 comprises any system, server, or function adapted to receivecharging messages from network elements that are serving the session,such as S-CSCF 112 and handover application server 114, and to generateCharging Data Records (CDR) for the session. For example, chargingsystem 116 may comprise a Charging Data Function (CDF)/Charging GatewayFunction (CGF) as defined by the 3GPP in Release 6, or a ChargingCollector Function (CCF) as defined by the 3GPP in Release 5. Billingsystem 120 comprises any system, server, or function adapted to processCDRs to generate or resolve a bill for a session in IMS network 110.

In this embodiment, assume that dual mode device 106 registers with IMSnetwork 110 and has initiated or is invited into a session with anendpoint 140. Further assume that the session is initially over accessnetwork 102. Thus, a first session leg is established between dual modedevice 106 and endpoint 140 using access network 102 as the means ofaccess to IMS network 110.

At initiation of the session, a network element in IMS network 110 willassign a charging identifier to the session. A charging identifiercomprises any number, code, string, etc, that is assigned in IMS network110 and used to correlate charging information for the session. Anexample of a charging identifier is an IMS Charging Identifier (ICID).As an example of assigning a charging identifier, if dual mode device106 initiates the session with a session initiation message (e.g., SIPINVITE), then a P-CSCF (not shown), a media gateway (not shown), oranother element receiving the session initiation message will assign thecharging identifier that is unique to that session. More particularly,the charging identifier is unique to the session leg. The chargingidentifier that is originally or initially assigned to the session isreferred to herein as the original charging identifier.

When S-CSCF 112 receives a session initiation message (e.g., a SIPINVITE) for the session, which is initiated by either dual mode device106 or endpoint 140, S-CSCF 112 processes initial filter criteria (iFC)for dual mode device 106 and identifies that dual mode device 106 hasdual mode capabilities and may initiate a handover at some point duringthe session. S-CSCF 112 then transmits the appropriate signalingmessages to handover application server 114 to include handoverapplication server 114 in the session.

S-CSCF 112, handover application server 114, and other network elements(not shown) in IMS network 110 have Charging Trigger Functions (CTF)that are defined to provide offline charging for the session. When a CTFin a network element (e.g., S-CSCF 112 or handover application server114) identifies a triggering event, the network element generates acharging message for the session. The charging message may be a start,interim, or stop message. As an example, the charging message maycomprise an Accounting Request (ACR) [start, interim, stop] message asdefined in Diameter Rf protocol. The network element inserts theoriginal charging identifier in the charging message, along with othercharging information, and then transmits the charging message tocharging system 116.

Assume at some point that dual mode device 106 initiates a transfer ofthe session from access network 102 to access network 103, which isreferred to as a handover. The desire for a handover may be for avariety of reasons. For instance, assume that access network 102comprises a GSM network and access network 103 comprises a WiFi network.When the session is initiated, dual mode device 106 may only be in rangeof the GSM network (i.e., access network 102). As some later time, dualmode device 106 may move into range of the WiFi network (i.e., accessnetwork 103). Service through the WiFi network may be less expensive andmay provide higher bandwidth than the GSM network, so dual mode device106 determines that a transfer from the GSM network to the WiFi networkwould be beneficial. Such logic may be programmed in dual mode device106 or initiated by the user of dual mode device 106.

To initiate the transfer, dual mode device 106 may transmit a sessioninitiation message (e.g., SIP INVITE) to IMS network 110 through accessnetwork 103. S-CSCF 112 receives the session initiation message, andcommunicates with handover application server 114 to establish a secondsession leg between dual mode device 106 and endpoint 140 using accessnetwork 103 as the means of access to IMS network 110. The sessioncontinues uninterrupted over the second session leg.

At initiation of the second session leg, a network element in IMSnetwork 110 will assign another charging identifier (e.g., an ICID) tothe session. For example, if dual mode device 106 initiates the sessionwith a session initiation message (e.g., SIP INVITE), then a P-CSCF (notshown), a media gateway (not shown), or another element receiving thesession initiation message will assign another charging identifier. Thecharging identifier that is assigned responsive to a handover isreferred to herein as the handover charging identifier.

As described in the Background, if the network elements in IMS network110 generate charging messages as described above, some of the networkelements will generate charging messages that include the handovercharging identifier instead of the original charging identifier, whichcauses problems. The following embodiments provide improved methods andsystems for charging for the session that has been transferred fromaccess network 102 to access network 103.

FIG. 2 is a flow chart illustrating a method 200 of generating chargingmessages in network elements in IMS network 110 in an exemplaryembodiment of the invention. The steps of method 200 will be describedwith reference to communication network 100 in FIG. 1. The steps of theflow chart in FIG. 2 are not all inclusive and may include other stepsnot shown.

In step 202 of method 200, a network element, such as S-CSCF 112 orhandover application server 114, identifies a triggering event forcharging during the session, such as based on a Charging TriggerFunction (CTF). In step 204, the network element identifies a transferof the session from access network 102 to access network 103. A networkelement may identify the transfer of the session in a variety of ways.For example, handover application server 114 provides the service ofhandling handovers in IMS network 110. Thus, handover application server114 is able to identify a transfer of the session from access network102 to access network 103 based on signaling received for the session.Handover application server 114 may provide an indication of thetransfer to other network elements.

In step 206, the network element identifies the handover chargingidentifier assigned to the session over access network 102 (i.e., thesecond session leg) in addition to the original charging identifierassigned to the session over access network 103 (i.e., the first sessionleg). The network element may identify the handover charging identifierin a variety of ways. For example, handover application server 114maintains a database entry for the session for dual mode device 106. Thedatabase entry may include the directory numbers for dual mode device106, the present status of dual mode device 106, etc. Handoverapplication server 114 may also maintain a list of charging identifiersassigned to the session, such as the original charging identifier andone or more handover charging identifiers. Handover application server114 may then use this list to identify the original charging identifierand the handover charging identifier for the session, and may alsoprovide this information to other network elements in IMS network 110.

In steps 208 and 210, the network element generates a charging messagefor the session, and inserts the handover charging identifier and theoriginal charging identifier in the charging message. When inserting theoriginal charging identifier in the charging message, the chargingmessage will have a parameter already designated for original chargingidentifier. For example, in a Diameter ACR message, there is anattribute value pair (AVP) designated for the original chargingidentifier. To insert the handover charging identifier, a new parametermay be designated for the handover charging identifier. For example, anew AVP in a Diameter ACR message may be designated for the handovercharging identifier. In step 212, the network element transmits thecharging message to charging system 116.

FIG. 3 is a flow chart illustrating a method 300 of processing chargingmessages in charging system 116 to generate CDRs in an exemplaryembodiment of the invention. The steps of method 300 will be describedwith reference to communication network 100 in FIG. 1. The steps of theflow chart in FIG. 3 are not all inclusive and may include other stepsnot shown.

In step 302 of method 300, charging system 116 receives the chargingmessage from the network element (i.e., S-CSCF 112 or handoverapplication server 114). Charging system 116 may additionally receivecharging messages from other network elements. In step 304, chargingsystem 116 processes the charging message to identify the originalcharging identifier and the handover charging identifier. In step 306,charging system 116 inserts the original charging identifier and thehandover charging identifier in a Charging Data Record (CDR) for thesession. When inserting the original charging identifier in the CDR, theCDR will have a field already designated for original chargingidentifier. To insert the handover charging identifier, a new field maybe designated in the CDR for the handover charging identifier. Chargingsystem 116 then inserts the handover charging identifier in the new CDRfield.

Step 306 assumes that a CDR is already open for this network element orfor this dialog involving the network element. If a CDR is not alreadyopen, then charging system 116 opens the CDR. Those skilled in the artwill appreciate that charging system 116 will close the CDR at somepoint. For instance, charging system 116 may receive a stop chargingmessage, such as an ACR[stop] message, which causes charging system 116to close the CDR.

Charging system 116 will most likely generate multiple CDRs for thesession based on charging messages received from multiple networkelements. Charging system 116 also provides the function of correlatingCDRs for the session when the session is terminated. Because at leastone of the CDRs include both the original charging identifier and thehandover charging identifier, charging system 116 is able to effectivelycorrelate the CDRs as described below.

FIG. 4 is a flow chart illustrating a method 400 of correlating CDRs incharging system 116 in an exemplary embodiment of the invention. Thesteps of method 400 will be described with reference to communicationnetwork 100 in FIG. 1. The steps of the flow chart in FIG. 4 are not allinclusive and may include other steps not shown.

In step 402 of method 400, charging system 116 processes the originalcharging identifier and the handover charging identifier in the CDR toidentify other CDRs for the session having one or both of the originalcharging identifier and the handover charging identifier. For example,charging system 116 may be programmed to process the field in the CDRfor the original charging identifier, and also process the field in theCDR for the handover charging identifier. When the charging identifiersare determined for the session, charging system 116 is able to identifyall other CDRs that include the same charging identifiers, as these CDRsbelong to the same session.

In step 404, charging system 116 correlates the CDRs for the sessionbased on the original charging identifier and the handover chargingidentifier. Correlating the CDRs means forming some type of associationbetween the CDRs so that they may be processed in a billing domain toprovide billing for the session. Some of the CDRs for the session maynot have both the original charging identifier and the handover chargingidentifier. For example, the CDRs that were generated prior to thehandover will have the original charging identifier. Some of the CDRsthat were generated after the handover may have only the originalcharging identifier or only the handover charging identifier. However,as long as one or more of the CDRs generated for the session includeboth the original charging identifier and the handover chargingidentifier, then charging system 116 has the proper information tocorrelate the CDRs for the session.

In step 406, charging system 116 transmits the correlated CDRs tobilling system 120. Billing system 120 may then process the correlatedCDRs to generate a bill for the session.

If another handover occurs from access network 103 to yet another accessnetwork which is not shown in FIG. 1, then a similar process isperformed to report the new handover charging identifier to chargingsystem 116. Charging system 116 will then be able to correlate CDRsbased on the original charging identifier, the first handover chargingidentifier, and the second handover charging identifier.

The above methods provide an effective way of correlating charginginformation and CDRs for a session where handover has occurred fromaccess network 102 to access network 103. Because both the originalcharging identifier and the handover charging identifier are reported tocharging system 116 and inserted in one or more CDRs, charging system116 is able to identify CDRs for the same session even though the CDRsmay have different charging identifiers. As a result, more accuratecharging may be realized for the session.

In addition to reporting the handover charging identifier to chargingsystem 116, the network element may also provide additional handoverinformation to charging system 116. One type of handover informationthat may be reported is a handover timestamp (i.e., a time when thehandover occurred). For example, in step 206 of FIG. 2, the networkelement may additionally identify a timestamp of the transfer of thesession from access network 102 to access network 103, which is referredto herein as a handover timestamp. In step 210, the network element mayinsert the handover timestamp in the charging message. To insert thehandover timestamp, a new parameter may be designated in the chargingmessage. For example, a new AVP in a Diameter ACR message may bedesignated for the handover timestamp.

Charging system 116 then processes the handover timestamp in thecharging message, and inserts the handover timestamp in the CDR. Toinsert the handover timestamp, a new field may be designated in the CDR,and charging system 116 inserts the handover timestamp in the new CDRfield. The handover timestamp may then be used in billing system 120 toadjust billing based on how long each access network 102-103 is used.For example, a GSM network may be billed at a higher rate than a WiFinetwork, so the billing is adjusted depending on how long the sessionwas over the GSM network versus how long the session was over the WiFinetwork.

Another type of handover information that may be reported is a handoverindication (i.e., indicating that the transfer is from one type ofaccess network to another type of access network). For example, in step210 in FIG. 2, the network element may also insert a handover indicatorin the charging message indicating the transfer of the session fromaccess network 102 to access network 103. The handover indication may bein variety of forms. For instance, the handover indication may indicatethat the session has been seamlessly handed over from a GSM network to aWiFi network, from a WiFi network to a CDMA network, etc. To insert thehandover indication, a new parameter may be designated in the chargingmessage. For example, a new AVP in a Diameter ACR message may bedesignated for the handover indication.

Charging system 116 then processes the handover indication in thecharging message, and inserts the handover indication in the CDR. Toinsert the handover indication, a new field may be designated in theCDR, and charging system 116 inserts the handover indication in the newCDR field. The handover indication may then be used in billing system120 for a variety of reasons.

Example

FIGS. 5-8 illustrate an example of charging for a session that isseamlessly handed over from one access network to another accessnetwork. FIG. 5 illustrates a communication network 500 in an exemplaryembodiment of the invention. Communication network 500 includes a GSMnetwork 502, a WiFi network 503, and IMS network 110. The IMS network110 in FIG. 5 further includes a media gateway control function (MGCF)512 and a P-CSCF 514. The example in FIGS. 5-8 illustrates a seamlesshandover from GSM network 502 to WiFi network 503 when dual mode device106 is invited to a session by endpoint 140.

FIGS. 6-8 are message diagrams illustrating messaging used in thesession in an exemplary embodiment of the invention. The message diagramillustrates SIP and Diameter messaging used within communication network500, although other protocols may be used in other embodiments. Assumethat an IMS endpoint 140 (see FIG. 5) wants to initiate a session withdual mode device 106 (DMD).

To initiate the session in FIG. 6, endpoint 140 generates a SIP INVITEmessage and transmits the INVITE message to the appropriate networkelement in IMS network 110. The network element receiving the INVITEmessage assigns an original ICID for the session, and the INVITE isultimately forwarded to S-CSCF 112. The INVITE message (dialog 1)includes a session description that is designated by endpoint 140(illustrated as SDP FE) in FIG. 6. The INVITE message also includes theoriginal ICID for the session (indicated as ICID “A” in FIG. 6) which isinserted in the P-Charging-Vector of the INVITE message. Responsive tothe INVITE message inviting dual mode device 106 to a session, S-CSCF112 processes initial filter criteria (iFC) for dual mode device 106,which indicates that dual mode device 106 has dual mode functionality.Thus, S-CSCF 112 includes handover application server 114 (HO AS/VCC AS)in the session by transmitting a SIP INVITE message to handoverapplication server 114 (dialog 2).

Handover application server 114 is a back-to-back user agent (B2BUA) inthis embodiment (as is S-CSCF 112), so handover application server 114transmits a SIP INVITE message (dialog 3) back to S-CSCF 112. S-CSCF 112then transmits an INVITE message to a BGCF (not shown) which furtherroutes the INVITE message to MGCF 512. MGCF 512 converts the INVITEmessage to the appropriate signaling message used in GSM network 502,and transmits the signaling message to dual mode device 106. At thispoint, dual mode device 106 and endpoint 140 may perform SDPnegotiation.

Dual mode device 106 then transmits an acceptance of the session to MGCF512 responsive to which MGCF 512 generates a SIP 200 OK message (dialog4) and transmits the 200 OK message to S-CSCF 112. The 200 OK message inS-CSCF 112 is a trigger for the CTF in S-CSCF 112. Thus, S-CSCF 112generates a Diameter ACR[start] message for dialog 4, inserts theoriginal ICID (ICID “A”) in the ACR[start] message, and transmits theACR[start] message to charging system 116. Responsive to the ACR[start]message, charging system 116 opens a CDR for S-CSCF 112 (dialog 4) andinserts ICID A into the CDR.

S-CSCF 112 also transmits the 200 OK message to handover applicationserver 114. The 200 OK message in handover application server 114 isalso a trigger for the CTF in handover application server 114. Thus,handover application server 114 generates a Diameter ACR[start] messagefor dialog 3, inserts the original ICID (ICID “A”) in the ACR[start]message, and transmits the ACR[start] message to charging system 116.Responsive to the ACR[start] message, charging system 116 opens a CDRfor handover application server 114 (dialog 3) and inserts ICID A intothe CDR.

Handover application server 114 then transmits a 200 OK message (dialog2) back to S-CSCF 112. Responsive to the 200 OK message, S-CSCF 112generates a Diameter ACR[start] message for dialog 2, inserts theoriginal ICID (ICID “A”) in the ACR[start] message, and transmits theACR[start] message to charging system 116. Responsive to the ACR[start]message, charging system 116 opens a CDR for S-CSCF 112 (dialog 2) andinserts ICID A into the CDR. S-CSCF 112 then transmits the 200 OKmessage to endpoint 140. The bearer channel is then established for thesession, which is typically a Realtime Transport Protocol (RTP) channel.Dual mode device 106 and endpoint 140 may then communicate during thesession via voice, text, multimedia, etc. There are four dialogsestablished to set up and maintain the session. These four dialogs (1-4)represent a first session leg.

The session at this point is over GSM network 502 which is acting as theaccess network (see FIG. 5). Assume further for this embodiment thatdual mode device 106 comes into the service area of WiFi network 503 andregisters with WiFi network 503. Dual mode device 106 may be programmedto request a transfer (or handover) from a GSM network 502 to a WiFinetwork 503 due to cost considerations, bandwidth considerations, etc.

To initiate the handover, dual mode device 106 transmits a SIP INVITEmessage to P-CSCF 514 through WiFi network 503. P-CSCF 514 assignsanother ICID to the session, which is referred to as the handover ICID(ICID “B” in FIG. 6). P-CSCF 514 then transmits the INVITE message toS-CSCF 112. The INVITE message (dialog 5) includes a session descriptionthat is designated by dual mode device 106 (illustrated as SDP HO-DN) inFIG. 6. The INVITE message also includes the handover ICID for thesession (indicated as ICID “B” in FIG. 6) which is inserted in theP-Charging-Vector of the INVITE message. Responsive to the INVITEmessage inviting dual mode device 106 to a session, S-CSCF 112 processesthe initial filter criteria (iFC) for dual mode device 106, whichindicates that dual mode device 106 has dual mode functionality. Thus,S-CSCF 112 includes handover application server 114 (HO AS) in thesession by transmitting a SIP INVITE message to handover applicationserver 114 (dialog 6).

Handover application server 114 transmits a SIP re-INVITE message(dialog 2) back to S-CSCF 112. S-CSCF 112 then transmits a re-INVITEmessage (dialog 1) to endpoint 140. At this point, dual mode device 106and endpoint 140 may perform SDP negotiation. In FIG. 7, endpoint 140responds with a 200 OK (dialog 1) message to S-CSCF 112. In response tothe 200 OK message, S-CSCF 112 generates a Diameter ACR[interim] messagefor dialog 1, inserts the original ICID (ICID “A”) in the ACR[interim]message, and transmits the ACR[interim] message to charging system 116.Responsive to the ACR[interim] message, charging system 116 updates theCDR for S-CSCF 112 (dialog 1). Even though a handover ICID has beenassigned to the session, the dialogs 1-4 of the first session leg stilluse the original ICID.

S-CSCF 112 also transmits the 200 OK message to handover applicationserver 114. Handover application server 114 identifies a triggeringevent for the session, which is the receipt of the 200 OK message.Handover application server 114 also identifies a transfer of thesession from the GSM network 502 to WiFi network 503. For instance, whenhandover application server 114 receives the INVITE from S-CSCF 112 totransfer the session to WiFi network 503 (see FIG. 6), handoverapplication server 114 may update a database entry for dual mode device106 indicating that the session has been handed over, the time when thesession was handed over, that the session was handed from a GSM network502 to a WiFi network 503, etc. Responsive to a determination that thesession has been handed over, handover application server 114 identifiesthe handover ICID and the original ICID for the session. Handoverapplication server 114 then generates a Diameter ACR[interim] messagefor dialog 2, inserts the original ICID (ICID “A”) and the handover ICID(ICID “B”) in the ACR[interim] message, and transmits the ACR[interim]message to charging system 116. A new parameter may be designated in theACR message for the handover ICID. For example, a new AVP in theACR[interim] message and other ACR messages may be designated for thehandover ICID. Responsive to the ACR[interim] message, charging system116 updates a CDR for handover application server 114 (dialog 2) andinserts ICID A and ICID B into the CDR.

One assumption here is that a CDR for handover application server 114(dialog 2) has already been opened. For instance, before handoverapplication server 114 transmits the ACR[interim] message to chargingsystem 116 responsive to the 200 OK message, handover application server114 may send an ACR[interim] responsive to a time limit expiration.Prior to the 200 OK message for dialog 2, handover application server114 may generate an ACR[interim] message, insert the original ICID (ICID“A”) in the ACR[interim] message, and transmit the ACR[interim] messageto charging system 116. Responsive to the ACR[interim] message, chargingsystem 116 opens an incomplete CDR for handover application server 114(dialog 2) and inserts ICID A into the CDR.

Handover application server 114 then transmits a 200 OK message (dialog6) to S-CSCF 112. Responsive to the 200 OK message, S-CSCF 112 generatesa Diameter ACR[start] message for dialog 6, inserts the handover ICID(ICID “B”) in the ACR[start] message, and transmits the ACR[start]message to charging system 116. Responsive to the ACR[start] message,charging system 116 opens a CDR for S-CSCF 112 (dialog 6) and insertsICID B into the CDR. S-CSCF 112 then transmits the 200 OK message(dialog 5) to P-CSCF 514, which in turn forwards the 200 OK message todual mode device 106. The bearer channel is then established for thesession, with the session now being over WiFi network 503 which isacting as the access network (see FIG. 5). Dual mode device 106 andendpoint 140 may then communicate during the session via voice, text,multimedia, etc. There are two additional dialogs established to set upand maintain the session. These two dialogs (5-6) represent a secondsession leg.

After the second session leg is established and the handover iscompleted, handover application server 114 initiates the tear down thedialogs over GSM network 502. Handover application server 114 thusgenerates a SIP BYE message (dialog 3), and transmits the BYE message toS-CSCF 112. S-CSCF 112 forwards the BYE message (dialog 4) to MGCF 512.MGCF 512 converts the BYE message to the appropriate signaling messageused in GSM network 502, and transmits the signaling message to dualmode device 106.

Responsive to the BYE message, S-CSCF 112 generates a Diameter ACR[stop]message for dialog 4, inserts the original ICID (ICID “A”) in theACR[stop] message, and transmits the ACR[stop] message to chargingsystem 116. Responsive to the ACR[stop] message, charging system 116closes the CDR for S-CSCF 112 (dialog 4), which includes only ICID A.The bearer channel for the session over GSM network 502 is then torndown.

Assume at some later point that dual mode device 106 terminates thesession, which is illustrated in FIG. 8. Dual mode device 106 terminatesthe session by generating a SIP BYE message and transmitting the BYEmessage to P-CSCF 514. P-CSCF 514 transmits the BYE message (dialog 5)to S-CSCF 112. In response to the BYE message, S-CSCF 112 transmits aBYE message (dialog 6) to handover application server 114. S-CSCF 112also generates a Diameter ACR[stop] message for dialog 5, inserts thehandover ICID (ICID “B”) in the ACR[stop] message, and transmits theACR[stop] message to charging system 116. Responsive to the ACR[stop]message, charging system 116 closes the CDR for S-CSCF 112 (dialog 5),which includes only ICID B.

Handover application server 114 then identifies a triggering event forthe session, which is the receipt of the BYE message. Handoverapplication server 114 also identifies a transfer of the session fromthe GSM network 502 to WiFi network 503. Responsive to a determinationthat the session has been handed over, handover application server 114identifies the handover ICID and the original ICID for the session.Handover application server 114 then generates a Diameter ACR[stop]message for dialog 6, inserts the original ICID (ICID “A”) and thehandover ICID (ICID “B”) in the ACR[stop] message, and transmits theACR[stop] message to charging system 116. Responsive to the ACR[stop]message, charging system 116 closes the CDR for handover applicationserver 114 (dialog 6), which includes both ICID A and ICID B.

Handover application server 114 then responds to S-CSCF 112 with a BYEmessage for dialog 2). S-CSCF 112 generates a Diameter ACR[stop] messagefor dialog 2, inserts the original ICID (ICID “A”) in the ACR[stop]message, and transmits the ACR[stop] message to charging system 116.Responsive to the ACR[stop] message, charging system 116 closes the CDRfor S-CSCF 112 (dialog 2), which includes only ICID A. S-CSCF 112 alsotransmits a BYE message (dialog 1) to endpoint 140. Additional SIPmessages may then be exchanged to tear down the second session leg andend the session.

When the session is terminated, charging system 116 will have generatedmultiple full CDRs for S-CSCF 112. The CDR(s) regarding the firstsession leg (dialogs 1-4) involving S-CSCF 112 will have only theoriginal ICID (i.e., ICID A). The CDR(s) regarding the second sessionleg (dialogs 5-6) will have only the handover ICID (i.e., ICID B).

Charging system 116 will also have generated a full CDR for handoverapplication server 114. The CDR for handover application server 114 willinclude both the original ICID and the handover ICID. Because handoverapplication server 114 facilitates the transfer of the session from GSMnetwork 502 to WiFi network 503, handover application server 114 is ableto identify when a transfer occurred and also identify both the ICIDsthat have been assigned to the session. Handover application server 114may thus report both the ICIDs in an ACR message to charging system 116.Responsive to receiving the ACR message from handover application server114, charging system 116 processes the ACR message to identify theoriginal ICID and the handover ICID. A new CDR field may be designatedfor the handover ICID into which charging system 116 inserts thehandover ICID.

After the session is terminated, charging system 116 is able tocorrelate the CDRs for the session using the original ICID and thehandover ICID. For example, there may be multiple CDRs for S-CSCF 112,with some of the CDRs having the original ICID and some having thehandover ICID. Similarly, there may be CDRs for MGCF 512 having theoriginal ICID, and CDRs for P-CSCF 514 having the handover ICID.Charging system 116 processes the original ICID and the handover ICID inthe CDR from handover application server 114 to identify other CDRs forthe session that have either the original ICID or and the handover ICID.Charging system 116 then correlates the CDRs for the session based onthe original ICID and the handover ICID. When the CDRs are correlated,charging system 116 transmits the correlated CDRs to billing system 120.

Although specific embodiments were described herein, the scope of theinvention is not limited to those specific embodiments. The scope of theinvention is defined by the following claims and any equivalentsthereof.

1. An IMS network adapted to provide charging for a session of a dualmode device that is transferred from a first access network to a secondaccess network, the IMS network comprising: a charging system; and anetwork element adapted to identify a triggering event for chargingduring the session, to identify a transfer of the session from the firstaccess network to the second access network, to identify a handovercharging identifier assigned to the session over the second accessnetwork in addition to an original charging identifier assigned to thesession over the first access network, to generate a charging messagefor the session and insert the handover charging identifier and theoriginal charging identifier in the charging message, and to transmitthe charging message to the charging system.
 2. The IMS network of claim1 wherein the network element is further adapted to: insert a handoverindicator in the charging message indicating the transfer of the sessionfrom the first access network to the second access network.
 3. The IMSnetwork of claim 2 wherein the network element is further adapted to:identify a timestamp of the transfer of the session from the firstaccess network to the second access network; and insert the timestamp inthe charging message.
 4. The IMS network of claim 3 wherein the chargingmessage comprises a Diameter charging message, and the network elementis further adapted to: insert the handover charging identifier in afirst new attribute value pair (AVP) in the Diameter charging message;insert the handover indicator in a second new attribute value pair (AVP)in the Diameter charging message; and insert the timestamp in a thirdnew attribute value pair (AVP) in the Diameter charging message.
 5. TheIMS network of claim 1 wherein the charging system is adapted to:receive the charging message from the network element; process thecharging message to identify the original charging identifier and thehandover charging identifier; and insert the original chargingidentifier and the handover charging identifier in a Charging DataRecord (CDR) for the session.
 6. The IMS network of claim 5 wherein thecharging system is further adapted to: process the charging message tofurther identify additional handover information; and insert theadditional handover information in the CDR.
 7. The IMS network of claim6 wherein the additional handover information includes at least one of ahandover timestamp and a handover indication.
 8. The IMS network ofclaim 5 wherein the charging system is further adapted to: process theoriginal charging identifier and the handover charging identifier in theCDR to identify other CDRs for the session having at least one of theoriginal charging identifier and the handover charging identifier;correlate the CDRs for the session based on the original chargingidentifier and the handover charging identifier; and transmit thecorrelated CDRs to a billing system.
 9. A method of providing chargingfor a session of a dual mode device that is transferred from a firstaccess network to a second access network, the method comprising:identifying a triggering event for charging during the session;identifying a transfer of the session from the first access network tothe second access network; identifying a handover charging identifierassigned to the session over the second access network in addition to anoriginal charging identifier assigned to the session over the firstaccess network; generating a charging message for the session; andinserting the handover charging identifier and the original chargingidentifier in the charging message.
 10. The method of claim 9 furthercomprising: inserting a handover indicator in the charging messageindicating the transfer of the session from the first access network tothe second access network.
 11. The method of claim 10 furthercomprising: identifying a timestamp of the transfer of the session fromthe first access network to the second access network; and inserting thetimestamp in the charging message.
 12. The method of claim 11 whereinthe charging message comprises a Diameter charging message, and themethod further comprises: inserting the handover charging identifier ina first new attribute value pair (AVP) in the Diameter charging message;inserting the handover indicator in a second new attribute value pair(AVP) in the Diameter charging message; and inserting the timestamp in athird new attribute value pair (AVP) in the Diameter charging message.13. The method of claim 9 further comprising: processing the chargingmessage to identify the original charging identifier and the handovercharging identifier; and inserting the original charging identifier andthe handover charging identifier in a Charging Data Record (CDR) for thesession.
 14. The method of claim 13 further comprising: processing thecharging message to further identify additional handover information;and inserting the additional handover information in the CDR.
 15. Themethod of claim 14 wherein the additional handover information includesat least one of a handover timestamp and a handover indication.
 16. Themethod of claim 15 further comprising: processing the original chargingidentifier and the handover charging identifier in the CDR to identifyother CDRs for the session having at least one of the original chargingidentifier and the handover charging identifier; and correlating theCDRs for the session based on the original charging identifier and thehandover charging identifier.
 17. An IMS network adapted to providecharging for a session, the IMS network comprising: a charging system;and a network element adapted to receive signaling for a first leg ofthe session identified by a first charging identifier, to initiate asecond leg of the session identified by a second charging identifier, togenerate a charging message for the session responsive to a triggeringevent, to insert the first charging identifier and the second chargingidentifier in the charging message, and to transmit the charging messageto the charging system.
 18. The IMS network of claim 17 wherein thecharging system is adapted to: receive the charging message from thenetwork element; process the charging message to identify the firstcharging identifier and the second charging identifier; and insert thefirst charging identifier and the second charging identifier in aCharging Data Record (CDR) for the session.
 19. The IMS network of claim18 wherein the charging system is further adapted to: process the firstcharging identifier and the second charging identifier in the CDR toidentify other CDRs for the session having at least one of the firstcharging identifier and the second charging identifier; correlate theCDRs for the session based on the first charging identifier and thesecond charging identifier; and transmit the correlated CDRs to abilling system.
 20. The IMS network of claim 17 wherein the networkelement comprises a handover application server adapted to initiate thesecond leg of the session responsive to a dual mode device transferringthe session from a first access network to a second access network.